IAM in OT: A Realist’s Guide

The convergence of IT and Operational Technology (OT) is no longer a future trend; it is the current reality. While this integration creates efficiency, it also exposes critical industrial processes to a new class of risks. Traditional security-perimeters, such as firewalls and assumed “air gaps,” were designed for a static, isolated environment and are often insufficient for today’s connected plant.

The core vulnerability is not the new technology itself. It is the legacy access model—built on implicit trust—that persists within flat, legacy OT networks.

Identity and Access Management (IAM) in Operational Technology (OT) is not a conventional IT project. It is a fundamental safety, availability, and business continuity imperative. Many initiatives falter because they attempt to apply a standard IT security model to a specialized OT problem.

This framework dissects the problem and presents a prioritized, OT-centric approach.

The Central Conflict: Why IT’s IAM Model Fails in OT

The primary challenge is the misapplication of an IT-centric security model to an OT environment. The models are driven by different, conflicting priorities:

• IT Model (CIA): 1. Confidentiality, 2. Integrity, 3. Availability. The worst-case scenario is a data breach.
• OT/ICS Model (AIC): 1. Availability & Safety, 2. Integrity, 3. Confidentiality. The worst-case scenario is a process failure, a safety incident, or a critical infrastructure outage.

IAM in OT is fundamentally a physical safety and process integrity function. Every “identity” represents a potential control point capable of manipulating the physical world.

A second common failure is defining “identity” too narrowly. In OT/ICS, human users are often not the primary risk. The vast majority of identities are non-human:

• PLCs
• Sensors
• Actuators
• HMIs
• Historians
• Remote Terminal Units (RTUs)
• Applications and services (SCADA, MES)

If a sensor cannot be uniquely identified and authenticated, its data cannot be trusted. If a command from an HMI cannot be authorized, process integrity is at risk.

---

Deconstructing the OT Identity Problem

The focus must shift from “users” to “identities and access vectors.”

1. The Identities (The “Who” and “What”)

The attack surface is defined by who—and what—can interact with the control system.

• Internal Operators & Engineers: Often operate with shared accounts (“operator,” “admin”) and universal passwords. This creates a significant risk of accidental—or malicious—action and removes accountability.
• Third-Party & Remote Access: This vector is a common critical vulnerability. Contractors and vendors often have persistent, high-privilege VPN access with shared credentials, creating a near-total lack of oversight.
• System & Service Accounts: These “invisible” identities (e.g., an HMI communicating with a PLC) are frequently managed with hard-coded, static passwords. A breach of one can provide a permanent, hidden foothold for an adversary.

2. The Access (The “How” and “Why”)

Access in OT is not about data access; it is about controlling physical processes.

• Read-Only: A view of the HMI or process data.
• Modify Parameters: Change a setpoint or an alarm threshold.
• Program/Change Logic: Fundamentally alter the function of a controller (e.g., change PLC logic).
• Operate: Start/stop a process or piece of equipment.

These actions must be mapped to specific roles. Access should be granted based on the principle of least privilege. For example, why does an external vendor require 24/7 programming access for a 2-hour, pre-scheduled maintenance window?

---

An Action Plan: Prioritized OT-IAM Practices

This is a sequential plan. Each step builds the foundation for the next.

1. Stop Guessing: Achieve Visibility First

Effective management is impossible without a clear inventory.

• Asset Inventory: Catalog every PLC, HMI, workstation, network switch, and server.
• Identity Inventory: Consolidate all shared accounts, service accounts, and local admin passwords from insecure spreadsheets into a secure, central vault.

2. Build Defenses: Segmentation & Least Privilege

Flat networks are the core architectural risk.

• Network Segmentation: Use the Purdue Model as a guiding concept, not a rigid dogma. Create zones to isolate the control network (L0-L2) from plant supervision (L3) and the business network (L4/L5). Enforce these boundaries with internal firewalls.
• Enforce Least Privilege: This is the most powerful control. Define roles (Role-Based Access Control) and institute a “Default Deny” policy. Access is a privilege, not a right, and should be granted only as necessary for a specific job.

3. Control Privileged Access: PAM & MFA

Privileged access represents the highest risk.

• Privileged Access Management (PAM): This is non-negotiable for OT. A PAM solution vaults all shared, admin, and service account credentials. All privileged access (especially remote) must be brokered through a PAM solution that acts as a jump server, recording the session. This session monitoring itself deters improper behavior. The PAM system, not humans, should manage and rotate these credentials automatically.
• Multi-Factor Authentication (MFA): Apply MFA strategically. Applying it to a physical HMI that an operator needs in three seconds can be dangerous and counter-productive. Applying it to all remote access and all privileged engineering workstation logins is mandatory.

4. Secure the Vector: The Remote Access Nightmare

This is the most common vector for major incidents.

• No More Persistent VPNs: All third-party access must be temporary, approved, and time-boxed. A vendor should request access, a manager should approve it for a specific window, and the access must be automatically revoked.
• Audited Jump Hosts: All remote access logs into a single, hardened jump host (ideally via the PAM solution). They never touch the control network directly, and their actions are fully auditable.

5. Integrate and Audit: The Governance Layer

• Centralize Identity: Connect the OT IAM solution to IT’s HR systems (e.g., Active Directory). The “joiner-mover-leaver” process must be automated. When an employee leaves the company, their access to the control system must be instantly and automatically de-provisioned.
• Audit, Audit, Audit: Generate unified, human-readable reports: Who accessed what, when, from where, and why. This accountability loop is what ultimately drives cultural change.

---

The Cost of Inaction

This transformation is complex. It requires investment and, critically, bridges the organizational and cultural gap between IT and OT.

The alternative, however, is a far greater operational risk.

A single ransomware event that shuts down a production line will cost multiples of a multi-year IAM program. A single malicious or accidental change by an unsupervised, un-audited third party can trigger a safety incident, stop production, or damage millions in equipment.

It is time to stop treating OT security as a low-priority IT problem. It is a high-priority operational risk that business leadership must own. This framework provides the technical path; the organization must provide the will to execute it.